The invention relates generally to process control systems and, more specifically, to a system and method for automatically configuring a remote input/output (I/O) communication link in a process control system.
Modern process control systems are typically microprocessor-based distributed control systems (DCSs). A traditional DCS configuration includes one or more user interface devices, such as workstations, connected by a databus (e.g., Ethernet) to one or more controllers. The controllers are generally physically close to a controlled process and are in communication with numerous electronic monitoring devices and field devices such as electronic sensors, transmitters, current-to-pressure transducers, valve positioners, etc. that are located throughout the process.
In a traditional DCS, control tasks are distributed by providing a control algorithm within each of the controllers. The controllers independently execute the control algorithms to control the field devices coupled to the controllers. This decentralization of control tasks provides greater overall system flexibility. For example, if a user desires to add a new process or part of a process to the DCS, the user can add an additional controller (having an appropriate control algorithm) connected to appropriate sensors, actuators, etc. Alternatively, if the user desires to modify an existing process, new control parameters or control algorithms may, for example, be downloaded from a user interface to an appropriate controller via the databus.
To provide for improved modularity and inter-manufacturer compatibility, process controls manufacturers have more recently moved toward even further decentralization of control within a process. These more recent approaches are based on xe2x80x9csmartxe2x80x9d field devices that communicate using an open protocol such as the HART(copyright), PROFIBUS(copyright), WORLDFLIP(copyright), Device-Net(copyright), CAN, and FIELDBUS(copyright) protocols. These smart field devices are essentially microprocessor-based devices such as sensors, actuators, etc. that, in some cases, such as with Fieldbus devices, also perform control loop functions traditionally executed by a DCS controller. Because some smart field devices provide control capability and communicate using an open protocol, field devices from a variety of manufacturers can communicate with one another on a common digital databus and can interoperate to execute a control loop without the intervention of a traditional DCS controller.
In conventional process control systems, field devices may be connected directly to a controller or, alternatively, may be connected to one or more I/O devices that are communicatively coupled to the controller via a databus. Generally speaking, these I/O devices process analog and/or digital information provided by the field devices and send the processed information as digital messages containing control signals, device information, etc. to the controller over the controller databus. Additionally, the controller can send digital messages containing configuration information, commands, etc. over the controller databus to the I/O devices. The digital messages sent by the controller to the I/O devices may be used to change the manner in which the I/O devices process signals received from the field devices and/or may be used to send signals to the field devices. Traditional I/O devices send and receive analog and digital signals, such as 4-20 mA, 0-10 VDC, dry contact closures, etc., to and from standard field devices. More recently, however, linking or bridge I/O devices have become available that enable a network of smart field devices, such as the Fieldbus devices discussed above, to communicate with the controller using digital messages via the controller databus.
In practice, I/O devices are typically located physically close to the field devices to which they are connected and may reside on a common mounting rail that facilitates their connection to a power source and to the controller databus. Thus, in applications where some of the field devices are physically remote from the locus of the process control system, it becomes desirable to locate some of the I/O devices so that these I/O devices are close to the remotely situated field devices. However, simply extending the controller databus to connect with remotely situated or remote I/O devices presents significant difficulties because the controller databus is typically not suitable for reliable communications over the required distance to the remote I/O devices.
A variety of well-known communication media (e.g., wireless, fiber optic, coaxial cable, etc.) and communication protocols (e.g., High Speed Ethernet) are available for long distance communications and, generally speaking, can provide a reliable remote communication link between remote I/O devices and a controller. While these known techniques for accomplishing remote communications may allow controllers to communicate with remote I/O devices (and the field devices associated with the remote I/O devices), they do not allow a seamless integration of the remote I/O devices within a process control system. For example, because the controller databus and the communication link to the remote I/O devices typically use different media and/or different communication protocols, the controller may communicate with the remote I/O devices via a remote I/O interface device that requires intensive manual integration by the user.
The integration of the remote I/O interface may involve a device-by-device configuration requiring the user to manually define and instantiate complex communication links for routing information between the controller and the remote I/O devices via the remote I/O communication link. As a result, the system user must be proficient with the particular communication configuration attributes associated with the local I/O devices and must additionally be proficient with the particular communication configuration attributes of the remote I/O interface device, which may be remarkably different from the communication configuration attributes of the local I/O devices. This intensive manual integration of remote I/O devices is undesirable because the xe2x80x9clook and feelxe2x80x9d of the system is inconsistent when the user attempts to incorporate remote I/O devices into a control loop of a local controller. For example, a graphical interface may allow a user to associate icons representing devices to establish connections (e.g., using a mouse or any other conventional computer-based pointing device) in a control loop between local I/O devices, but may require the user to define control loop connections to remote I/O devices using a completely different method, such as, for example, entering a series of textual commands via a keyboard connected to the user interface.
The system and method described herein enables the seamless integration of remotely situated I/O devices within a process control system. Generally speaking, the system and method automatically configures a remote I/O interface device at each end of a remote I/O communication link so that all communication activities (e.g., configuration, runtime reporting, user requests for information via the user interface, etc.) with the remote I/O devices over the remote I/O communication link appear to be transparent from the perspective of a user at a user interface and a controller that is communicating over the remote I/O communication link.
More specifically, the system and method automatically establishes communication objects in the pair of remote I/O interface devices situated at respective ends of the remote I/O communication link. In particular, a local communication object is established in the remote I/O interface which is connected to the controller and a remote communication object is established in the remote I/O interface which is connected to the remote I/O devices. The communication objects provide communication links that enable the routing of communications between the controller and the remote I/O devices via the remote I/O communication link.
One particularly interesting aspect of the system and method described herein is that the user can interact at the system level through a graphic interface running on the user interface, for example, to configure control loops, monitor process parameters, etc. associated with a combination of local and remote I/O devices, which may be communicating using one or more communication technologies (i.e., media and/or protocols), without having to understand, or even be aware of, the underlying communication technologies. In other words, the system and method described herein insulates the user from the implementation details of the underlying remote I/O communication technologies by automatically generating and instantiating appropriate communication objects (e.g., the local and remote communication objects) within the remote I/O interface devices in response to the user requesting a control loop connection to a remote I/O device. In one embodiment, the system and method automatically recognizes that the user has requested communications (e.g., via a control loop connection) with a remote I/O device that requires communications via the remote I/O communication link, creates communication objects to enable and carry out these remote communications, and loads these communication objects in the appropriate I/O devices during configuration to provide the communications specified by the user. As a result, the user only needs to understand how to use the graphical interface, for example, to interact with the control system and the user""s interaction with the system has a consistent look and feel regardless of whether or not the user has specified a connection to a remote or to a local I/O device and regardless of the underlying communication technologies being used to accomplish the remote I/O communications.
In accordance with one aspect of the invention, a method of configuring a communication link for use in a distributed process control system having a controller, a first remote I/O interface communicatively coupled to the controller and a remote I/O communication link, a second remote I/O interface communicatively coupled to the remote I/O communication link, and an I/O device communicatively coupled to the second remote I/O interface, specifies a connection between the controller and the I/O device. The method may recognize that the remote connection requires communications over the remote I/O communication link and automatically generate a first communication object that automatically routes communications between the controller and the remote I/O communication link and may also automatically generate a second communication object that automatically routes communications between the remote I/O communication link and the I/O device.
The method may further automatically generate the first communication object so that the first communication object receives communications having a first signal protocol and converts the communications to be sent using a second signal protocol and may generate the second communication object so that the second communication object receives communications having the second signal protocol and converts the communications to be sent using the first signal protocol.